Operations Office Interface and Module
This page is a discussion of the Operations Office Sub-Module. The Operations Office Sub-Module is designed to handle the Operations office interface; more specifically it is designed to display and playback Starport Notices and Evaluations. The basic architecture of the module is similar to other modules within the game that handle basic data types (such as integers and strings) and hash tables / dictionaries. This module is required by the Starport Module only. The Operations sub-module is important to the game because it acts as another means to divulge important clues to the player, help immerse them in the Starflight universe, and function as the means through which the player learns about the results of their colonization efforts. All code for the Operations sub-module is located in the sf3_starport_ops.py file. Summary Description An ofc_Ops object is created and stored during the initialization of a Starport office if a certain flag is set to True. When created, the ofc_Ops object will load in the current list of Starport Notices into a holder dictionary, checking the display status of those messages as it does so. It will then check to see if the player has made any evaluations or launched any colony pods since the last time they visited a Starport. If so, those efforts at colonization are evaluated and an appropriate message is seeded for display into a holder dictionary. Finally, if another flag is set to True, the interface will be set to have a Library access button available; another routine will load in library data to a third holder dictionary (again, checking for the display status of the data as it does so). The Operations interface comes up when the player enters the Operations office; when an option is selected from that menu, the appropriate data is displayed to the player. The object remains in memory until the player leaves the star system in which the office's Starport is located, at which point the object is destroyed (along with its parent Starport object). Data Structure of the ofc_Ops Object The following list is an indication of the various variables and methods that will be included in an ofc_Ops object. This list contains suggested methods and variables only; they should be updated as needed when finalized method and variable names are selected. Ofc_Ops objects are meant to be used as child objects of Starport objects, and have no child objects. Ofc_Ops objects are created during runtime when a player enters a star system and are subsequently destroyed when they leave that system. Thus, while there may be multiple ofc_Ops objects used in the game, only one will be in existence at a time (per Starport located in a system; the Flornea system has two Starports in it and thus '''may' have two ofc_Ops objects in it as well, one for each base''). Their data structure is as follows: *Class: ofc_Ops **Hash/Dictionary: hNotices ***''Key: Message ID ***Tuple: Message and Status ****Flag: Message Lock (True locks the message; it won't display) ****String: Message Text'' **List/Vector: vEvals ***''String: Evaluation Message ***Integer: Value'' **Hash/Dictionary: hLibrary ***''Key: Entry Name ***Tuple (String, Flag): Entry Info, Locked?'' **Method: __init(bLibLock)__ **Method: unlockMsg(msg_ID) Interface The Operations Office interface consists only of two main areas, as demonstrated in the graphic: * Message Box * Interface Buttons The Message Box takes up the bulk of the screen and is by far and away the largest area on screen. As the name suggests, this area is used to show every message the player will receive while still in the Operations office. Immediately below the Message Box along the bottom of the screen are the Interface Buttons. There are four such buttons, one to call up Starport Notices, one for Evaluations, one for Library Access, and a fourth to Exit (ignore the "Bank Balance" one in the graphic; apparently at one time the Bank would've been merged in with the Operations office. Instead, this is where the "Library Access", will be located). The Library Access button may or may not be accessible depending on whether or not the method is instructed to activate it or not; if not, the button may either be dimmed, or simply set not to appear in the interface (this is going to depend on how we set it up). The Notices button is highlighted every time the player enters the Operations Office. Selecting an Interface Button may either be done via a mouse click or by using the keyboard arrow keys followed by the key; once an option is selected, the player will have to use the arrow keys to continue to scroll through the various messages. The selection cursor will scroll, so pushing the left arrow key when the cursor is on the "Notices" button will move the cursor to "Quit" (and vice versa). When selected by the cursor, a specific button will turn red. The selection of a menu option will sound the ACKNOWLEDGED tone and activate a pre-programmed method (as defined in the XML file). As with all Starport modules, no calls will be made to the gameClock object to advance the time while the interface is active. General Procedures and Notes Notices from Interstel given over time or given in response to major plot events. The purpose of these notices is to give the player hints to start off with, announce major events, give the player a sense of accomplishment and demonstrate consequences of actions, and of course humor. (notices - include initial mission briefing messages, clues and helpful info, and humorous company personals). Evaluations are messages from Interstel to the player usually with a monetary reward or penalty. Examples include colony recommendation rewards and penalties, loss of a terrain vehicle and notice of its replacement, rewards for major plot events, etc. (evaluation - evaluations of player's recommendations of colonies; fine or bonus given for each recommendation. Was a major part of the original games.) Library entries can be as big or as small as we want them. The samples I've got in the XML discussion are pretty basic; building the entries is going to be fairly time consuming and should probably be one of the last things we do with the game before its final completion. For reference, sapient race entries will probably have as much text data as in their profile. Need to incorporate "dynamic messages" into Operations module (as per ICC plot discussion thread, 12/17/06). Main idea was to have messages show up that specifically indicate the ship's captain and ship's name. Should be doable through the event handler. Just need to have a few dynamic messages to add. MNMinstrel Starport Notice post from ICC, 3/1/11 10:09 CST: "Earth History: Compelling new evidence about political unrest in the Afspamistan region during the early 21st century confirms that Veloxi spies were supplying the Talispam with spam bots. " Note from the Casino Module page, 4/4/11: "What happens at Starport stays at Starport, baby." (Might be recyclable as a Starport Notice.) 4/13/11: quote from MNMinstrel: "Djaboon Foot fungus fetish!!!" 5/9/11: Google has launched Google Earth because Android Burrey underpants xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx TO: INTERSTEL OPERATIONS, STARPORT CENTRAL FROM: ISS PATRIOT STARDATE: 15.31-11-2006 RE: ALPHA SECTOR SURVEY NNNNNNNNNNNNN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THIS MIGHT BE A BAD TIME TO BRING THIS UP, BUT I HAVE A BUNCH OF RECEIPTS FOR THE ENDURIUM I USED DURING THIS MISSION. WHO DO I NEED TO GIVE THESE TO, AND WHEN CAN I EXPECT COMPENSATION? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BREAKBREAK BORNO, ALL YOUR BASE ARE BELONG TO US. XENON. Methods __init(bLibLock)__ unlockMsg(msg_ID) XML The ofc_Ops object, like most of the other objects in the game, is largely XML driven; this will help keep it flexible up until SF3's design is finalized (i.e. notices, evaluation messages and library data can be added and removed from the game freely, based upon what data is available in the XML files). The ofc_Ops object requires three different XML files, containing the game's list of notices (the file "starport_notices.xml"), the list of evaluation messages, (the file "colonization_evals.xml"), and the library access information (the file "LCARS.xml"). The following briefly goes over what data is located in these XML files. starport_notices.xml The file "starport_notices.xml" is designed as a listing of the possible messages a player may receive when visiting the Operations office at Starport; these messages are meant to immerse the player in the universe and to sometimes provide clues as to what they need to do to fulfill their mission. Under the root element, entries in the XML file are empty "notice" elements, each containing a mandatory "msg" attribute (which contains the message text). Notices may need to take up multiple messages; the routine that displays them on screen will look for the "escape" character of "/n" to denote new lines. The escape character of "/t" may also be used to add tab stops to the message. Additional tags may be added later if it is decided they are needed; these would be tags to record a specific date, the names of specific ships and captains, and so forth. Sample structure of the starport_notices.xml file: colonization_evals.xml The file "colonization_evals.xml" is designed as a listing of the possible messages a player may receive if they submit a planet for colonization or launch a colony pod, designed to let them know the efforts of their colonization efforts (for more information on submitting evaluations and launching colony pods, see the discussion under the Starship Module. Entries in the XML file are empty elements under the root element, and may either have the name "recommend" (used for evaluation of planetary colonization efforts, either through recommending a planet for colonization or by establishing a colony there using a colony pod) or "supplement" (used for other types of evaluation messages, such as fulfillment of victory conditions, applications of fines, and so forth; messages generated from the Lounge Module are of this type; see the discussion on that page). Regardless of the element type, the inclusion of an "msg" attribute (used to hold the text of the evaluation message) and a "type" attribute (used to denote the message's purpose) is mandatory. Type attributes may have one (and only one) of the following values associated with them: *'optimal': the message is used whenever the player has established a colony on an optimally habitable world, or has located an optimally habitable planet to colonize. *'normal': the message is used whenever the player has successfully established a colony on a non-optimal world, or has located an non-optimal planet to colonize. *'firstFail': the message is used the first time the player fails to establish a colony, or recommends a non-habitable world. Usually includes the reasons for failure. *'fail': the message is used any subsequent time the player fails to establish a colony, or recommends a non-habitable world. Usually includes the reasons for failure. *'towed': the message is displayed at Starport after the player has issued a distress call and must be towed back to the closest Starport. *'victory': the message is displayed after the player has fulfilled a set of victory conditions. Can be used for the overall game victory conditions. *'defeat': the message is displayed after the player can no longer fulfill a set of victory conditions. Both recommend and supplement messages types may be long, and so will utilize the same set of escape characters as the starport_notices.xml file. In addition, an escape character of "*" may be used to list reasons for a failed colonization result, and "$" may be used to list a specific monetary amount (with what that amount represents - a bonus or a fine - dependent upon the type involved). Sample structure of the colonization_evals.xml file: LCARS.xml The file "LCARS.xml" is designed as a list of library access materials on species, lifeforms, artifacts, starships, and star systems; it's essentially meant as a reference for the player (and potentially a means of providing clues in game). Under the root element, entries in the XML file are empty elements with the name "entry". These elements must contain exactly three attributes, one named "id" (which is used as the library access entry name), one called "lock" (which must either be set equal to true or false, and indicates whether the entry is "locked and shadowed" (i.e. not visible in the list of library access entries) at the game's onset), and one called "text" (which is used to contain the text of the library entry). Text attributes may be long and so will utilize the same set of escape characters as the starport_notices.xml file. Sample structure of the LCARS.xml file: Module Status This is current as of May 3, 2011. This module is currently in the final design phases; while specific descriptions of the intended functions of modules have yet to be written, the remainder of the module's basic description is complete at this point. Further design work on this module has been frozen for the time being, and will remain so until I'm ready to begin method descriptions for all remaining extant modules. ---- NEXT: Bank Module and Interface PREVIOUS: Starport TOP ----